The Universal Mobile Telecommunication Service (UMTS) standard provides a compatibility standard for cellular mobile telecommunications systems. The UMTS standard ensures that a mobile station (MS), or user equipment (UE), operating in a UMTS system can obtain communication services when operating in a system manufactured according to the standard. To ensure compatibility, radio system parameters and data transfer procedures are specified by the standard, including protocols governing digital control messages and bearer traffic that are exchanged over an air interface.
The UMTS standards provide, in 3GPP TS 25.346 (Third Generation Partnership Project Technical Specification 25.346) v0.5.0, 3GPP TS 23.246 v1.1.0, and 3GPP TS 23.846 v6.0.0, for a provision of a Multimedia Broadcast Multicast Service (MBMS) service by a UMTS communication system to MSs serviced by the system and subscribed to the service. When the MBMS service has MBMS data for conveyance to subscribers to the service, a Radio Network Controller (RNC) included in a Radio Access Network (RAN) of a UMTS infrastructure determines whether to establish a Point-To-Multipoint (PTM) communication channel in a cell or a Point-To-Point (PTP) communication channel to each UE in the cell. The RNC then broadcasts a MBMS notification via a Node B included in the RAN, typically a base transceiver station (BTS), and a control channel to all UEs in the cell. The notification typically includes an identifier associated with the MBMS service. In response to receiving the MBMS notification, each MS in the cell that subscribes to the MBMS service and is in idle mode wakes up. In addition, in response to receiving the MBMS notification, each MS in the cell that subscribes to the MBMS service conveys a connection request, typically a Radio Resource Control (RRC) connection establishment request, to the RNC via an access channel. Upon receiving the connection requests from each of the subscribing MSs, the RNC sets up a communication session by establishing a PTM communication channel or PTP communication channels with each responding MS, whichever the RNC has determined to establish, and conveys the MBMS data to the subscribing MSs over the established channel or channels.
One use of MBMS services may be to broadcast an event that includes multiple communication sessions. For example, a subscriber to an MBMS service may subscribe to a specific event, such as a soccer game. Rather than provide a continuous broadcast of the event, the MBMS service then broadcasts the event via multiple communication sessions, wherein each communication session of the multiple communication sessions concerns a separate aspect of the event, such as a video clip or text concerning of each of multiple goals, periodic score updates, and/or periodic game highlights. Each communication session of the multiple communication sessions is separately set up and provides for conveyance of MBMS data to subscribers to the event. However, a problem may arise when a subscriber to the event is outside a coverage area of the MBMS service for one or more of the multiple communication sessions or fails to acceptably receive data during one or more of the communication sessions, resulting in an incomplete transmission of data concerning the event to the subscriber. A further issue is how to re-convey data to a subscriber who wishes to view a replay of a clip or text.
In order to provide a subscriber to the event with more complete coverage of an event, concepts have been proposed for providing missing data or replays of data to subscribers to the event. In one proposal, an MS may request a replay based on a Session Identifier (Session ID). In this proposal, a Session ID is generated by an MBMS content provider or by an intermediate network element between the content provider and the RNC for each communication session of the multiple communication sessions. For example, a first communication session, such as a first goal, may be associated with a Session ID of ‘1,’ a second communication session, such as a second goal, may be associated with a Session ID of ‘2,’ and so on. The Session ID is then embedded by the network element generating the ID in a data packet associated with the communication session.
When the RNC receives data packets associated with a communication session, the RNC detects the embedded Session ID and stores the Session ID in association with the data packets. The RNC then broadcasts the MBMS data packets to the subscribers to the service. Upon receiving the data packets, an MS parses the data packets to obtain the Session ID and stores the Session ID. When a user of the MS wishes to see a replay of the text or video clip associated with the Session ID, the user pulls up a menu of stores Session IDs. The user then selects a Session ID from the menu of stored Session IDs and conveys the selected Session ID to the RNC. The RNC then re-conveys the data packets stored in association with the selected Session ID to the MS, thereby allowing the MS to replay the data for the user.
The use of Session IDs poses several problems. For one, the Session ID is not very descriptive of the communication session and may not provide the user of the UE with sufficient information for selecting a replay. For another, the RNC must detect and store Session IDs and further store data associated with each stored Session ID. This violates an expressed goal of MBMS service that replays and retransmissions of data should be transparent to the RAN. The use of Session IDs may also impose significant data storage requirements upon an RNC as MBMS services increase in popularity. In addition, the proposed use of Session IDs presents inter-layer, that is, inter-OSI layer, issues for the RNC and MS. The RNC would have to know the Session ID associated with a replay, and the MS will require higher and lower layer interaction in order to determine session status. By contrast, the OSI layers were established to separate functions performed by a communication device. Furthermore, the use of Session IDs to replay MBMS data does not assist late joiners to an event, that is, those who outside the coverage area of the MBMS service until after the event has begun, select a replay when they have missed earlier broadcasts of the event.
Another proposal is to provide missing data or replays of data based on a Sequence Identifier (Sequence ID). Similar to the Session IDs, a Sequence ID is generated by an MBMS content provider or by an intermediate element between the content provider and the RNC with respect to each communication session. For example, a first communication session, such as a first goal, may be associated with a Sequence ID of ‘1,’ a second communication session, such as a second goal, may be associated with a Sequence ID of ‘2,’ and so on. However, unlike the Session IDs, the Sequence IDs must be sequential and must be provided with each communication session. The Sequence ID is then embedded by the network element generating the Sequence ID in a data packet associated with the communication session.
When the RNC receives data packets associated with a communication session, the RNC detects the Sequence ID and stores the Sequence ID in association with the data packets. The RNC then broadcasts the MBMS data to the subscribers to the service. Upon correctly receiving a data broadcast, an MS parses the received data packets to obtain the Sequence ID and stores the Sequence ID, thereby storing a record of the received data. The MS may then determine, based on a gap in the stored Sequence IDs, whether a communication session has been missed and, upon determining that a communication session has been missed, convey the missing Sequence ID to the RNC. Upon receiving the Sequence ID from the MS, the RNC then retrieves the data associated with the Sequence ID and conveys the retrieved data to the MS.
The use of a Sequence ID poses many of the same problems as the use of the Session ID. In addition, the use of a Sequence ID has a drawback that late joiners to the event cannot obtain earlier data broadcasts, since Sequence IDs associated with the earlier data broadcasts are unknown to the UE.
Therefore, a need exists for a method and apparatus that provides for replays of MBMS data and for re-conveyance of missing MBMS data in a manner that is transparent to a RAN, that does not require inter-layer interaction, and that supports conveyance of missed MBMS data to late joiners to an event.